职护 产品需求文档 PRD
| 项目信息 | 内容 |
|---|---|
| 项目名称 | 职护 |
| Slogan | 你的职场全方位保障 |
| 项目类型 | AI 驱动的职场陪伴与决策辅助平台 |
| 目标用户 | 从在校学生到资深职场人（首期聚焦应届与职场新人） |
| 核心理念 | 像一个有经验的朋友，陪用户走过职场中的每一步 |
| 当前版本 | v0.2 产品规划稿 |
| 文档日期 | 2026 年 7 月 17 日 |
| 项目目标 | 解决求职、签约、入职、收入与成长过程中的真实问题 |
| 项目属性 | 实用型学生创新项目，兼顾作品比赛与后续持续开发 |
| 一句话定位 | 别人给你信息碎片，职护陪你把碎片拼成一个能行动的决定 |
一、项目背景
学生和年轻职场人在第一次找实习、选择 Offer、签署劳动合同、前往新城市工作时，往往会同时遇到大量陌生问题：一份实习是否值得去；薪资在市场中是否合理；Offer 中的年终奖和绩效是否可靠；劳动合同中是否存在需要注意的条款；税前工资最终能拿到多少；到新城市工作后每月能剩多少钱；工资条、社保和公积金是否计算正确；面对多个 Offer 应该如何选择；工作几年后是否适合跳槽。
这些问题并不是单纯的信息查询问题，而是相互关联的个人决策问题。例如，判断一份 Offer 是否合适，不能只看月薪，还需要综合考虑薪资结构、试用期、奖金、工作地点、当地生活成本、岗位成长空间、招聘市场水平以及个人偏好。现有工具通常只解决其中一个环节，用户需要在招聘网站、工资计算器、合同审查工具、政策文章和社交平台之间反复切换。信息虽然很多，但缺少一个能够结合用户实际情况、逐步解释并给出行动建议的工具。
二、为什么要做"职护"
"职护"希望解决的核心问题不是"用户找不到信息"，而是：
用户不知道哪些信息与自己有关，不知道应该如何判断，也不知道下一步该做什么。
因此，职护不定位为传统招聘平台、职场知识库或单一 AI 合同审查工具，而是一个覆盖重要职场节点的个人陪伴与决策辅助平台。产品主要提供三层价值。
第一层：帮助用户看清楚
平台整合职位市场、薪资、合同、城市生活成本及个人收入信息，把分散的数据转化成与用户当前处境有关的解释。
这份 Offer 的固定薪资接近同类岗位中位数，但绩效部分占比偏高，目前没有明确考核标准。
第二层：帮助用户想清楚
系统根据用户在意的收入、成长、稳定、城市、工作强度等因素，帮助用户比较不同选择，但不替用户做人生决定。
如果你更在意短期储蓄，杭州方案更合适；如果你更看重岗位方向，上海方案与目标职业更接近。
第三层：帮助用户做下去
系统将分析结论转化成可以执行的任务，包括：向 HR 确认的问题、谈薪话术、签约前检查清单、入职材料清单、工资条核对任务、社保和公积金提醒、储蓄目标计划。
三、项目愿景与设计原则
项目愿景
让第一次面对职场重要选择的人，也能够获得清楚、可信、可执行的帮助。
设计原则
1. 陪伴，而不是命令
产品通过逐步询问帮助用户理清问题，不使用居高临下或制造焦虑的表达。不推荐"检测到重大合同风险"，推荐"这一项目前没有写清楚，签之前建议向 HR 确认"。
2. 一步一步，而不是一次填完
复杂任务需要拆成多个步骤。每一步只询问当前分析所必需的信息，非必要信息允许跳过或使用默认估算。
3. 解释依据，而不是只给结论
平台应明确区分：用户上传材料中的事实、规则引擎的判断、计算公式得到的结果、职涯通提供的市场数据、AI 给出的综合建议。
4. 提供参考，而不是替用户决定
职护帮助用户比较不同方案，并说明不同选择适合什么目标。最终决定权始终属于用户。
5. 真实有用，而不是追求功能数量
每个功能都需要对应一个真实问题，并能够产生具体结果。首期不追求完整覆盖所有职场阶段。
6. 保护隐私，而不是默认收集
Offer、劳动合同和工资条属于敏感材料。用户应能够选择不保存原文件，并可以查看、导出或删除自己的数据。
四、目标用户
职护在长期规划上覆盖完整职场生命周期，但首期重点服务在校学生、应届毕业生和工作初期的年轻职场人。
| 用户类型 | 主要需求 | 首期优先级 |
|---|---|---|
| 在校学生 | 找实习、了解技能、判断实习薪资 | P1 |
| 实习生 | 实习协议、薪资、转正判断 | P1 |
| 应届毕业生 | Offer 对比、合同检查、入职准备 | P0 |
| 职场新人 | 工资条、社保、生活成本、储蓄 | P0 |
| 工作 3～5 年用户 | 跳槽、谈薪、家庭与城市选择 | P2 |
| 资深职场人 | 职业转型、住房和长期规划 | P3 |
核心用户画像（三个 persona）
小林（P0，应届毕业生）：即将本科毕业，第一次面对正式 Offer；收到杭州和上海两份 Offer；不了解月薪、绩效和年终奖之间的区别；不知道税后工资和生活结余；担心合同中存在不合理内容；需要在较短时间内作出决定，希望获得具体、容易理解的帮助。——对应 Offer 分析、对比、合同核对全链路。
阿哲（P1，实习生）：在校大三，拿到一份实习协议；分不清实习协议与劳动合同的区别，不确定实习工资是否合理，最关心转正条件写没写清楚。——对应实习协议解释与转正判断。
May（P0，职场新人）：入职三个月，第一份工资条比预期少了一千多元；不知道钱扣在哪、社保基数对不对。——对应工资条核对页，验证"发薪时用户会回来"的留存假设。
五、用户旅程
长期用户旅程仍可分为六个阶段，但这些阶段主要用于内容推荐和后台业务分类，不作为强制导航。
平台前台不要求用户先理解自己属于哪个阶段，而是直接询问"最近遇到了什么职场问题？"。用户可以从真实事件进入：我想找实习、我正在准备面试、我拿到 Offer 了、我准备签合同、我马上要去新城市、我收到工资条了、我正在考虑跳槽、我想规划储蓄。
六、产品定位与信息架构
6.1 产品定位
职护是一款以个人当前职场问题为入口，融合招聘市场数据、文档理解、规则判断和计算能力的陪伴式职场决策辅助产品。它不等同于招聘网站、职场内容社区、通用聊天机器人、法律咨询平台、记账或投资理财平台、单纯的合同风险检测工具。
6.2 一级导航
桌面端建议使用顶部导航或轻量侧栏，移动端使用底部导航。
| 导航 | 作用 |
|---|---|
| 今天 | 当前建议、正在进行的任务与重要提醒 |
| 一起看看 | 发起 Offer、合同、薪资、工资条等任务 |
| 我的旅程 | 展示从求职到入职的连续任务和完成情况 |
| 我的档案 | 管理个人情况、材料、报告及隐私设置 |
"职位市场"和"知识学堂"不建议首期作为一级导航。市场数据应嵌入具体任务，知识内容应在用户遇到相应问题时出现。
6.3 竞品对照与差异化
差异化的核心是从孤立工具走向连续闭环，并始终结合个人情况。
| 品类 | 代表 | 解决的环节 | 职护的差异 |
|---|---|---|---|
| 招聘平台 | Boss直聘、拉勾 | 找职位、投递 | 职护不做投递，只在拿到 Offer 后介入决策 |
| 点评/薪资 | 看准网、职友集 | 看公司口碑、薪资范围 | 把大盘数据转成"我的位置"，而非匿名爆料 |
| 合同/法务工具 | 通用合同审查 | 风险检测 | "说人话"解释＋生成确认话术，不止给风险分 |
| 计算工具 | 个税/五险一金计算器 | 单点算数 | 把计算嵌入 Offer 决策与工资条核对闭环 |
| 通用 AI | 通用聊天机器人 | 开放问答 | 用分步任务替代大段对话，结论可溯源 |
一句话差异化：别人给你信息碎片，职护陪你把碎片拼成一个能行动的决定。
七、核心功能范围
7.1 首期核心闭环
这条链路能够同时体现产品设计、招聘数据、AI 文档理解、规则引擎、薪资计算和长期陪伴。
7.2 功能优先级
P0：比赛版本必须完成
欢迎和轻量身份引导；陪伴式首页；Offer 上传、粘贴及手动录入；Offer 信息识别和用户确认；单份 Offer 分析；两份 Offer 对比；税后收入和城市生活结余计算；招聘市场薪资水平对比；HR 待确认问题及沟通话术；劳动合同上传、解析和风险说明；Offer 与合同一致性检查；签约前行动清单；我的职场旅程；用户数据删除及演示模式。
P1：增强真实使用价值
工资条上传和字段识别；实发工资校验；社保、公积金基础检查；入职第一周清单；目标岗位技能差距；轻量储蓄目标；城市生活成本自定义；分析报告导出。
P2：后续扩展
跳槽决策；谈薪策略；社保转移助手；年终奖计税比较；住房选址；买房计算；跨设备档案同步。
八、全局交互设计
8.1 陪伴式任务结构
所有复杂功能统一使用以下五步结构：
以 Offer 为例：用户选择"我拿到 Offer 了"；上传文件、粘贴文字或手动输入；系统提取公司、岗位、城市和薪资；用户确认并补充自己最在意的因素；系统生成分析结果、待确认事项与下一步行动。
8.2 步骤页面规则
每个步骤页面应遵循：一屏只完成一个主要任务；顶部显示当前进度，如"第 2 步，共 5 步"；主标题使用用户语言，如"这份工作在哪里？"；提供"暂时不知道"或"按当地水平估算"；系统识别的信息必须允许修改；上一步内容自动保留；用户退出后可继续；在提交敏感材料前显示隐私说明。
8.3 AI 的呈现方式
AI 不以悬浮聊天框作为唯一入口，而是嵌入任务流程：识别用户上传的 Offer 和合同；发现缺失信息并主动追问；将复杂条款翻译成通俗语言；结合计算和市场数据解释；生成沟通话术；在结论旁显示依据。AI 可采用"职护小助手"的视觉形象，但应克制，不建议使用过度拟人化的虚拟人物。
九、页面清单与页面描述
9.1 欢迎页
页面目标：向首次用户解释职护能提供什么帮助，并降低使用压力。
页面布局：页面中间采用单列布局，背景为米白或极浅灰绿色。首屏内容：
职场里的很多事，没人提前教过我们。 职护想陪你把眼前的问题一件件弄明白。
主按钮"从我现在的情况开始"，次级入口"先看看示例"。底部用三条短信息说明：不需要一次填写完整资料；重要结论会告诉你依据；上传材料可选择不保存。
交互：用户点击主按钮后进入轻量情况选择；点击示例则进入预置的小林 Offer 案例，适合比赛现场演示。
9.2 当前情况选择页
页面目标：了解用户目前处境，用于推荐任务，但不做复杂注册问卷。
页面布局：标题"你现在走到职场的哪一段了？"。采用六张可选择卡片：还在学校、正在实习、正在找工作、拿到 Offer 了、已经工作一段时间、正在考虑新机会。选择后询问一个轻量问题"你最近最想解决什么？"，用户可以选择问题，也可以输入自然语言。
交互：选择不同状态时，下方推荐内容实时变化。用户可以跳过，之后在"我的档案"中修改。
9.3 陪伴式首页——"今天"
页面目标：告诉用户现在最值得处理的事情，并提供轻量入口。
页面布局
顶部问候区——首次用户："嗨，最近在忙什么？不用一次想清楚，我们从你眼前这件事开始。"回访用户："距离回复 Offer 还有 3 天。还有两个薪资条件没有确认。"
当前行动卡——只突出一件最重要的任务："杭州 Offer：签之前还有 3 项需要确认"，按钮为"继续看看""稍后提醒我"。
快捷事件区——展示四个事件卡片：我拿到 Offer 了、我准备签合同、我想算算到手工资、我收到工资条了。
最近任务区——使用纵向时间线展示：已完成 Offer 信息确认、待完成 HR 问题确认、预计 7 月 25 日签约、预计 8 月 10 日入职。
与我有关的市场变化——最多展示两条与用户目标岗位有关的信息：杭州前端岗位近 30 天薪资中位数、目标岗位近期高频技能变化。
交互：首页不展示全部功能。任务完成后，系统根据旅程自动推荐下一步。
空状态文案：还没有任何任务时显示"还没有开始，先从眼前这件事看起吧"。
9.4 发起任务页——"一起看看"
页面目标：让用户快速选择需要帮助的问题。
页面布局：顶部输入框"说说你现在遇到了什么？"，用户可输入如"我收到了一份上海的 Offer，不知道值不值得去"。下方提供常用入口：
| 入口 | 对应任务 |
|---|---|
| 看看一份 Offer | 单份 Offer 分析 |
| 比较两份 Offer | Offer 对比 |
| 看看这份合同 | 合同解释与检查 |
| 算算真实到手 | 薪资计算 |
| 核对工资条 | 工资与扣款校验 |
| 去这个城市够不够花 | 生活成本评估 |
交互：自然语言输入由系统识别任务类型。如果信息不足，则通过分步卡片追问，不直接输出大段聊天回答。
9.5 Offer 材料提交页
页面目标：以最低操作成本获得 Offer 信息。
页面布局：标题"先让我看看这份 Offer 吧。"，提供三种方式：上传 PDF 或图片、粘贴文字、手动填写。上传区域说明"文件仅用于本次分析。你可以选择分析完成后自动删除原文件。"底部显示处理进度：正在读取文件、正在识别薪资和工作条件、已找到 12 项关键信息、有 3 项需要你确认。
交互：上传后进入识别确认页。识别失败时允许用户切换到粘贴或手动输入，采用"这份没太看清，换粘贴或手动填也一样"，不使用"系统异常"等冰冷提示。
9.6 Offer 信息确认页
页面目标：让用户确认 AI 从材料中提取的信息，防止模型识别错误直接影响结果。
页面布局：标题"我从 Offer 里看到了这些，帮我确认一下。"信息按卡片分组——基本信息（公司、岗位、城市、入职日期）；收入信息（月薪、一年发薪月数、固定工资、绩效工资、奖金、补贴、试用期工资）；工作条件（试用期、工作地点、工时制度、加班说明、调岗或地点调整约定）。识别不确定项（低置信度字段）使用浅橙色边框：
"年终奖 1～3 个月"——这是浮动范围，需要确认是否有保证值。
交互：每个字段可单独编辑，字段带置信度标记，低于阈值强制复核。修改后相关计算立即更新。用户确认后进入偏好设置页。
9.7 个人偏好页
页面目标：了解用户判断 Offer 时最在意的因素，使结果具有个性化。
页面布局：标题"选工作没有统一答案，你更在意什么？"用户最多选择三项并排序：收入、职业成长、稳定、工作强度、城市和生活、专业匹配、公司平台、通勤距离。随后询问必要补充信息：当前所在地、预计租房预算、每月生活支出、是否计划储蓄、目标岗位方向。
交互：所有问题允许选择"暂时不清楚"。系统可使用城市普通水平估算，但必须明确标记为估算值。
9.8 单份 Offer 分析报告页
页面目标：用通俗、行动导向的方式解释 Offer 是否值得继续考虑。
页面结构
第一屏：直接结论——"这份 Offer 可以继续考虑，但签之前建议问清楚 3 件事。"不首先显示综合分数，避免让用户只关注一个抽象数字。
收入卡——税前年包、固定年收入、浮动收入、试用期损失、预估月到手、扣除生活成本后的月结余。所有数字均可点击查看计算过程。
市场位置卡——该岗位在目标城市的薪资区间、当前 Offer 所处位置、样本数量和更新时间、数据来自职涯通市场数据。
需要确认的事项——按优先级展示：一定要问清、建议确认、可以进一步争取。
与个人目标的匹配——分别说明对收入目标的影响、对储蓄目标的影响、与目标岗位的匹配、可能的成长机会和不确定性。
下一步行动——按钮：生成 HR 提问清单、和另一份 Offer 比较、保存到我的旅程、准备检查合同。
交互：用户可切换"收入优先""成长优先"等观察角度，结论随偏好变化，但基础事实保持一致。
9.9 Offer 对比页
页面目标：帮助用户理解两份或多份 Offer 的真实差异。
页面布局：顶部横向展示 Offer A 和 Offer B，首期最多比较三份。
| 维度 | 展示方式 |
|---|---|
| 固定年收入 | 数字与对比条 |
| 预估税后收入 | 数字 |
| 城市生活成本 | 分项金额 |
| 月度可结余 | 强调展示 |
| 试用期损失 | 提示标签 |
| 市场薪资位置 | 百分位区间 |
| 职业方向匹配 | 匹配理由 |
| 工作条件确定性 | 已明确/待确认 |
| 主要风险 | 最多三项 |
页面底部不只输出"推荐 A"，而是给出条件化建议：
如果你更在意两年内的储蓄目标，A 更合适。 如果你更在意进入目标岗位方向，B 更接近你的计划。
交互：用户拖动偏好权重后，建议实时变化。系统需要显示"建议变化的原因"，不能只改变分数。
9.10 HR 问题与谈薪话术页
页面目标：把分析结果转化成用户可以直接使用的沟通内容。
页面布局：按主题分组（薪资结构、绩效和奖金、试用期、工作地点、工时和加班、社保和公积金、入职与合同）。每个问题包括：为什么要问、推荐问法、对方回答后应关注什么、勾选"已确认"。示例：
建议确认：绩效工资是否有明确考核标准 推荐问法："想再确认一下，Offer 中绩效部分的考核周期和发放条件是什么？是否有书面制度可以提前了解？"
交互：支持一键复制单条话术或生成一段完整消息。用户填写 HR 回复后，系统更新 Offer 状态。
9.11 合同上传与识别页
页面目标：读取劳动合同，并建立与对应 Offer 的关联。
页面布局：标题"签之前，我们一起再看一遍。"用户可选择关联已有 Offer 或单独检查合同。上传后系统识别：合同主体、岗位、薪资、工作地点、试用期、合同期限、工时制度、竞业限制、违约责任、解除条件。
交互：系统先确认合同类型，再进行规则检查。若文件质量不清晰，提示具体页码并允许用户补拍。
9.12 合同"说人话"阅读页
页面目标：让用户看懂合同内容，而不只是获得风险分数。
页面布局：桌面端采用左右分栏——左侧合同原文，右侧通俗解释与行动建议；移动端使用"原文—解释"上下卡片。条款分为：已写清楚、建议确认、需要重点注意、暂时无法判断。示例：
原文：乙方工作地点由甲方根据经营需要安排。 通俗解释：公司保留调整工作地点的空间，但目前没有说明范围。建议确认是否可能跨城市调动，以及调动前是否需要双方协商。
交互：点击右侧解释，左侧自动定位对应条款；点击原文高亮，也可查看规则依据和 Offer 中对应内容。
9.13 Offer 与合同一致性页
页面目标：检查正式合同是否与前期 Offer 或 HR 承诺一致。
页面布局：使用逐项对比卡片。
| 对比项 | Offer | 合同 |
|---|---|---|
| 月薪 | 15,000 元 | 12,000 元基本工资＋绩效 |
| 工作地点 | 杭州 | 根据业务需要调整 |
| 试用期 | 3 个月 | 6 个月 |
| 年终奖 | 1～3 个月 | 未写入 |
| 公积金 | 12% | 未明确 |
系统给出状态：一致、表述不同、合同中缺失、存在明显差异。
交互：点击差异项，可生成专门的确认话术，并加入签约前清单。
9.14 签约前行动清单页
页面目标：让用户从"知道问题"进入"完成确认"。
页面布局：标题"签之前，再确认好这几件事。"清单按优先级排序：必须确认、建议留存书面记录、签署时注意、签署后保存。每项支持查看原因、复制沟通话术、标记已完成、上传补充材料、设置提醒。全部完成后显示"关键事项已经确认完成。记得保存 Offer、合同和沟通记录。"产品不使用"绝对安全，可以签署"等承诺性语言。
9.15 薪资与生活结余页
页面目标：让用户理解"税前工资"到"实际生活结余"的全过程。
页面布局：收入流向以纵向结构展示。
用户可调整：城市、社保、公积金基数和比例、专项附加扣除、租金、通勤、餐饮、其他固定支出。
计算口径（新增）：到手工资的基础公式为
到手=税前−五险一金个人部分−个人所得税\text{到手} = \text{税前} - \text{五险一金个人部分} - \text{个人所得税}
到手=税前−五险一金个人部分−个人所得税
个税采用累计预扣法，需支持起征点、专项附加扣除（租房、赡养、子女教育等）、城市社保基数上下限。所有默认比例必须标注城市与更新时间，避免让估算值看起来像精确事实。
交互：参数变化后结果即时更新。默认值必须标明数据来源和更新时间。
9.16 工资条核对页
页面目标：核对实发工资是否与 Offer、合同及预估相符。
页面布局：支持上传图片、PDF 或手动填写。系统展示应发工资、基本工资、绩效、补贴、社保、公积金、个税、其他扣款、实发工资，并与历史预测比较：
本月实发比入职前预估少 1,280 元，主要来自绩效未发放和社保基数变化。
交互：点击差异项查看原因。无法确定的扣款标记为"需要向人事确认"，并生成询问模板。
9.17 我的职场旅程页
页面目标：串联 Offer、合同、入职和工资，而不是让各功能相互独立。
页面布局：采用纵向时间线——收到 Offer、完成 Offer 分析、确认 HR 问题、上传劳动合同、完成签约检查、入职准备、首月工资核对、试用期结束提醒。每个阶段显示完成状态、日期、相关文件、报告、下一步任务。
交互：用户可以从任一节点继续任务。系统根据当前状态只推荐一个主要行动。
9.18 我的职场档案页
页面目标：管理个人信息、职业目标、材料和隐私。
页面内容：基本情况（当前阶段、专业、毕业时间、工作年限、所在城市）；职业目标（目标岗位、目标城市、关注行业、已有技能、最在意的工作因素）；我的材料（Offer、劳动合同、工资条、分析报告）；隐私设置（是否保留原文件、是否保存识别后的结构化信息、一键删除单个任务、一键清空个人数据、导出个人数据、开启演示模式）。
十、视觉与文案规范
10.1 视觉关键词
温暖、清楚、克制、可信、有陪伴感。
推荐色彩：主色为低饱和蓝绿色，用于主要按钮、选中状态和路径；辅助色为米白、暖灰、浅杏色；成功色为柔和绿色；提醒色为暖橙色；高风险色克制使用橙红色；背景避免纯白大面积铺满，可使用极浅暖灰。
组件风格：页面大卡片圆角 16～20px；内部卡片圆角 10～14px；浅色细边框；阴影仅用于弹层或需要强调的当前任务；表单避免一次出现超过六个字段；图表优先使用区间条、对比条和时间线；图标使用统一的线性图标；动画用于步骤切换、完成反馈和渐进展开。
10.2 文案语气
| 工程化表达 | 职护表达 |
|---|---|
| 创建分析任务 | 一起看看 |
| 用户画像 | 我的职场情况 |
| 缺失参数 | 还差一点信息 |
| 系统识别失败 | 这一部分暂时没看清 |
| 合同风险检测 | 陪我看看这份合同 |
| 薪资计算器 | 到手到底有多少 |
| 风险等级高 | 这一条签之前一定要问清楚 |
| 提交表单 | 继续下一步 |
| 分析结果 | 我们看到了这些 |
| 异常扣款 | 这笔扣款需要确认 |
空状态与失败态文案（新增）：
| 场景 | 职护表达 |
|---|---|
| 还没有任何任务 | 还没有开始，先从眼前这件事看起吧 |
| 上传识别失败 | 这份没太看清，换粘贴或手动填也一样 |
| 市场数据暂缺 | 这个岗位样本还不多，先按城市水平给你参考 |
亲和不意味着回避事实。涉及重要差异时，文案仍需明确、直接。
十一、技术方案
11.1 总体原则
新建独立"职护"项目，重新设计用户端页面和业务流程，同时复用职涯通已有的数据抓取、清洗、数据库及查询能力。不建议直接在职涯通原有前端上修改，因为职涯通以职位搜索和数据分析为中心、页面信息密度高、偏平台和管理系统；而职护以个人任务和分步陪伴为中心，两者用户心智和交互方式明显不同，独立项目更容易形成清晰的比赛叙事。也不需要完全从零开发——职涯通已经具备成熟的数据基础设施，应作为职护的市场数据底座。
11.2 推荐技术栈
| 层级 | 推荐技术 | 主要用途 |
|---|---|---|
| 前端 | Next.js 14+、React、TypeScript | 新版职护用户端 |
| UI | MUI 或自建 Design System | 卡片、表单、步骤组件 |
| 样式 | CSS Modules 或 Tailwind CSS | 页面布局与主题系统 |
| 图表 | ECharts | 薪资区间、Offer 对比和趋势 |
| 状态管理 | Zustand | 分步任务和跨页面状态 |
| 表单 | React Hook Form＋Zod | 分步录入与数据校验 |
| 后端 | FastAPI（Python） | 用户任务、文档、报告与市场接口 |
| ORM | SQLAlchemy 2.x＋Alembic | 数据访问 |
| 主数据库 | MySQL | 用户、档案、任务和报告 |
| 市场数据库 | MySQL 8.0 | 职涯通岗位和公司数据 |
| 缓存与任务 | Redis | 缓存、解析任务与进度 |
| 文件存储 | 本地开发＋对象存储 | Offer、合同和工资条 |
| OCR | PyMuPDF＋Tesseract OCR | PDF 与图片文字识别 |
| 浏览器抓取 | Playwright＋BeautifulSoup | 复用职涯通 crawler |
| AI 接口 | OpenAI 兼容接口 | 文档提取、解释和话术 |
| 测试 | Pytest、Playwright Test | 后端与端到端测试 |
| 部署 | Docker Compose＋Nginx | 比赛演示和后续部署 |
11.3 系统结构
11.4 推荐的后端模块
backend/
├── api/
├── auth/
├── profiles/
├── journeys/
├── cases/
│ ├── offers/
│ ├── contracts/
│ └── payslips/
├── documents/
├── calculators/
├── rules/
├── market/
├── reports/
└── assistant/
其中：profiles 管理用户阶段、偏好和目标；journeys 管理连续任务和提醒；offers 负责 Offer 录入、提取和比较；contracts 负责合同解释和一致性检查；payslips 负责工资条识别和差异分析；documents 负责上传、OCR 和文件删除；calculators 负责薪资、税务和生活成本；rules 负责确定性条款规则；market 调用职涯通数据；reports 生成统一职护报告；assistant 负责 AI 追问、解释和话术生成。
11.5 AI 能力工程设计（新增）
为保证可信度，assistant 模块需遵循以下约束：
- 结构化抽取契约：LLM 输出必须约束为固定 JSON schema（对应 Offer/Contract 数据模型字段），用 Zod / Pydantic 校验，非结构化文本一律拒绝入库。
- 置信度与人工确认：每个抽取字段携带 confidence，低于阈值的字段在 9.6 确认页用浅橙边框强制用户复核。
- 溯源绑定：解释类输出必须携带
evidence_text（原文片段）与页码定位，支撑 9.12 的"点击解释定位原文"。 - 降级链路：模型不可用时，OCR＋规则引擎仍能产出基础结果，支撑 14.2 演示模式的"预生成结果"。
11.6 职涯通可复用内容
直接复用：crawler/pipeline.py 抓取编排能力、crawler/spider_com.py 公司招聘页抓取、Playwright 与 BeautifulSoup 页面处理、LLM 职位字段解析、数据清洗与日期薪资标准化、岗位去重、MySQL 招聘数据库、城市与岗位与薪资与技能聚合接口、爬虫监控与异常记录。
封装后复用：职位搜索 API、公司分析 API、技能趋势 API、AI 岗位趋势 API、城市和薪资统计、前端图表与请求工具。
不建议直接复用：职涯通原有后台式页面布局、高密度筛选栏、爬虫管理页面、管理端表格视觉、以职位列表为首页的信息架构。
十二、核心数据模型
12.1 用户档案
UserProfile
- id
- user_id
- career_stage
- graduation_date
- years_of_experience
- current_city
- target_cities
- target_roles
- skills
- priorities
- monthly_budget
- savings_goal
12.2 职场任务
CareerCase
- id
- user_id
- type
- title
- status
- current_step
- started_at
- deadline
- completed_at
type 可为：offer_analysis、offer_compare、contract_review、salary_estimate、payslip_check、onboarding、job_change。
12.3 Offer
Offer
- id
- case_id
- company_name
- job_title
- city
- monthly_salary
- salary_months
- fixed_salary
- variable_salary
- bonus
- allowance
- probation_months
- probation_salary_rate
- work_location
- working_hours
- start_date
- source_document_id
12.4 合同
Contract
- id
- case_id
- linked_offer_id
- employer
- contract_term
- probation
- salary_terms
- work_location
- working_hours
- non_compete
- penalty_terms
- termination_terms
- source_document_id
12.5 工资条（新增，支撑 P1）
Payslip
- id
- case_id
- linked_offer_id
- pay_month
- gross_salary
- base_salary
- performance
- allowance
- social_insurance
- housing_fund
- individual_tax
- other_deductions
- net_salary
- source_document_id
12.6 分析结论
Finding
- id
- case_id
- category
- severity
- title
- plain_explanation
- evidence_text
- evidence_source
- recommended_action
- confidence
evidence_source 用于区分：document、rule、calculation、market_data、ai_suggestion。
十三、AI 与规则引擎分工
不能把所有判断全部交给大模型。
| 模块 | 适合处理的内容 |
|---|---|
| OCR/文档解析 | 获取原始文字和页面位置 |
| LLM | 字段提取、语义理解、通俗解释、话术 |
| 规则引擎 | 试用期、合同字段缺失、固定规则检查 |
| 计算模块 | 税后工资、社保、公积金、生活结余 |
| 职涯通数据 | 薪资区间、岗位数量、技能趋势 |
| 用户偏好 | 个性化排序和条件化建议 |
所有重要结论需要保存依据，报告不得只显示模型生成的自然语言。
13.1 规则库示例
以下为示意，具体阈值以最新法规为准，规则库需版本化并定期核对法规。
| 规则类别 | 判断逻辑（示意） | 触发提示 |
|---|---|---|
| 试用期上限 | 依据合同期限反推试用期是否超上限 | 试用期可能偏长，签前确认 |
| 试用期工资 | 试用期工资是否低于转正工资约定下限 | 试用期工资比例需确认 |
| 竞业限制 | 是否约定补偿金 | 有竞业限制但未见补偿约定 |
| 关键字段缺失 | 年终奖/公积金/工作地点是否写入合同 | 此项 Offer 提过但合同未写 |
| Offer-合同差异 | 逐字段比对数值/文本 | 月薪表述不一致 |
关键原则：规则引擎只做"能确定的事实性判断"，凡涉及合理性、公平性的价值判断一律输出为"建议确认"而非"违法"结论，与 14.1 第 9 条呼应。
十四、隐私与安全需求
虽然项目以学生比赛为主要场景，仍需认真处理敏感数据。
14.1 基本要求
上传前说明文件用途；支持分析后自动删除原文件；文件访问使用权限校验；数据库中不保存不必要的原文；日志中不得记录完整合同、身份证号和工资信息；支持一键删除任务及相关文件；支持演示账号和脱敏示例材料；报告中对身份证号、电话、地址进行遮盖；明确说明 AI 建议不等同于法律意见；重要结论支持查看依据。
14.2 比赛演示模式
系统提供"演示模式"：使用虚构人物和公司；Offer、合同和工资条均为脱敏样例；一键恢复演示数据；不依赖现场上传真实敏感文件；网络或模型接口不可用时，可使用预生成结果。这能降低比赛现场演示失败的风险。
十五、非功能需求与度量体系
15.1 非功能需求
| 维度 | 要求 |
|---|---|
| 性能 | 普通页面首屏尽量在 2 秒内可交互 |
| 反馈 | 上传和分析超过 2 秒必须展示进度 |
| 可恢复性 | 用户中途退出后可以继续任务 |
| 响应式 | 支持桌面端和移动端 |
| 可解释性 | 重要结论可查看来源与计算过程 |
| 可访问性 | 文本和背景保持足够对比度 |
| 容错 | AI 提取失败后可手动录入 |
| 可维护性 | 市场数据与个人任务模块保持分离 |
| 可演示性 | 提供完整样例、预生成结果和降级方案 |
15.2 度量体系与北极星指标
北极星指标：完成一次完整闭环的用户比例（Offer 分析 → 合同核对 → 签约清单完成）。 它直接对应文末三个问题能否被回答。
| 层级 | 指标 | 说明 |
|---|---|---|
| 激活 | 首个任务完成率 | 上传 Offer 并确认信息的比例 |
| 核心价值 | 闭环完成率 | 走完 Offer→合同→清单的比例 |
| 有用性 | 生成话术被复制率 | 反映"帮用户做下去"是否真被用 |
| 信任 | 依据查看率 | 用户点击"查看计算过程/条款依据"的比例 |
| 修正质量 | 字段人工修改率 | 反向衡量 AI 抽取准确度 |
| 留存 | 旅程节点回访率 | 用户是否在签约、入职、发薪时回来 |
十六、项目比赛表达重点
16.1 项目问题陈述
第一次进入职场的年轻人，需要同时理解岗位、Offer、合同、工资、社保和新城市生活，但现有信息分散在多个平台，缺少结合个人情况的连续指引。职护通过陪伴式交互，将招聘市场数据、个人材料分析、确定性规则和计算工具连接起来，帮助用户看清选择、确认风险并完成下一步行动。
16.2 核心创新点
陪伴式任务交互——不要求用户理解复杂功能，而是从"我拿到 Offer 了"等真实事件出发，一步一步完成任务。
个人问题与市场数据结合——将职涯通的大盘招聘数据转化为"我的薪资处于什么位置""我的技能还缺什么""这份 Offer 与目标岗位是否匹配"。
多能力协同——系统并非只依赖大模型，而是结合 LLM、规则引擎、薪资计算、OCR、招聘市场数据和用户偏好。
跨阶段连续闭环——Offer、合同、入职和工资条并不是相互独立的工具，而是同一条职场旅程中的连续节点。
可信与隐私设计——用户可以查看依据、修改识别结果、删除材料，并明确区分事实、计算、规则和 AI 建议。
十七、比赛演示脚本
建议使用"小林第一次选择正式工作"的故事进行演示：小林即将毕业，收到杭州和上海两份 Offer；在首页选择"我拿到 Offer 了"；上传两份脱敏 Offer；系统识别薪资、绩效、试用期和工作地点；小林确认自己更看重成长和储蓄；系统调用职涯通数据比较市场薪资和岗位技能；系统计算税后收入和城市生活结余；发现上海 Offer 的绩效规则和工作地点未写清；系统生成 HR 问题和谈薪话术；小林选择其中一份 Offer；上传劳动合同；系统发现合同中的试用期与 Offer 不一致；小林完成签约前清单；系统创建入职和首月工资核对任务。整段演示应控制在 5～7 分钟，并优先展示完整故事，而不是介绍所有菜单。
十八、开发计划
第一阶段：产品原型与设计系统——完成用户旅程、信息架构、视觉规范、首页原型、Offer 分步流程、Offer 报告页、合同阅读页、我的旅程页、演示用户故事。这一阶段使用模拟数据，不急于连接全部后端。
第二阶段：Offer 决策闭环——完成文件上传、Offer 字段提取、手动修改、薪资计算、生活成本、职涯通薪资数据、两份 Offer 对比、HR 问题清单。
第三阶段：合同签约闭环——完成 PDF 和 OCR、合同字段提取、规则引擎、通俗解释、Offer 与合同一致性检查、签约前清单。
第四阶段：长期陪伴和比赛优化——完成我的旅程、入职提醒、工资条核对、隐私设置、演示模式、降级数据、项目说明书、演示视频和答辩材料。
十九、项目验收标准
首个可参赛版本至少应满足：用户可从首页进入 Offer 分析；可通过上传、粘贴或手动方式添加 Offer；系统提取内容后允许用户确认和修改；可计算预估到手收入和生活结余；可展示招聘市场薪资位置；可比较两份 Offer；可生成有依据的 HR 问题；可上传并解释劳动合同；可发现 Offer 与合同的主要差异；可生成签约前清单；所有重要结论可查看来源；用户可删除上传材料；提供稳定的比赛演示模式；整体页面保持陪伴式、分步骤、非后台化风格。
职护首版最重要的成功标准，不是页面数量或模型参数，而是用户走完一次流程后，能够明确回答三个问题：
这份工作真实能给我什么？ 签之前还有什么需要确认？ 我接下来应该做什么？
附录 A：页面追溯矩阵
| 页面 | 依赖能力 | 主要数据模型 | 优先级 |
|---|---|---|---|
| 9.5 Offer 提交 | OCR＋LLM | Offer / CareerCase | P0 |
| 9.6 信息确认 | LLM 抽取＋置信度 | Offer | P0 |
| 9.8 Offer 报告 | 计算＋市场数据＋规则 | Offer / Finding | P0 |
| 9.9 Offer 对比 | 计算＋市场数据＋偏好 | Offer / UserProfile | P0 |
| 9.10 HR 话术 | LLM＋Finding | Finding | P0 |
| 9.12 合同阅读 | OCR＋LLM＋规则 | Contract / Finding | P0 |
| 9.13 一致性检查 | 规则比对 | Offer / Contract | P0 |
| 9.15 薪资结余 | 计算引擎＋市场数据 | Offer / UserProfile | P0 |
| 9.16 工资条核对 | OCR＋计算 | Payslip / Finding | P1 |
| 9.17 我的旅程 | 任务编排 | CareerCase | P0 |
附录 B：风险登记表
| 风险 | 影响 | 应对 |
|---|---|---|
| OCR/抽取不准 | 结论错误、失信 | 强制确认页＋手动录入兜底 |
| 现场网络/模型不可用 | 演示失败 | 演示模式＋预生成结果 |
| 法规规则过时 | 误导用户 | 规则库版本化＋"非法律意见"声明 |
| 敏感文件泄露 | 合规风险 | 可选不留原文＋一键删除＋日志脱敏 |
| 功能过多导致做不完 | 比赛完成度低 | 严守 P0 闭环，P1/P2 后置 |
VibeCoding 导航：⬅️ 05-红软先锋——码上校园 | 06-职护产品需求文档 PRD | ➡️ 07-辅助工具
💬 评论